Systems and methods for adapting compressor controller based on field conditions

ABSTRACT

An antisurge controller for a turbocompressor system stores multiple control algorithms in a memory for the antisurge controller. The antisurge controller identifies capabilities of field devices in the turbocompressor system. The field devices include an antisurge valve and multiple sensors. The antisurge controller selects one of the multiple control algorithms based on the identified capabilities and applies the selected control algorithm to the turbocompressor system. The selected control algorithm provides the smallest surge control margin, of the surge control margins in the multiple control algorithms, that are supported by the identified capabilities.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority under 35 U.S.C. § 119, based on U.S.Provisional Patent Application No. 62/801,759 filed Feb. 6, 2019, titled“Systems and Methods for Adapting Compressor Controller Based on FieldConditions,” the disclosure of which is hereby, incorporated byreference.

BACKGROUND OF THE INVENTION

Compressor surge of axial and centrifugal turbocompressors can lead tocompressor damage. Surge may be considered an event where the compressorcan no longer maintain an adequate pressure difference to continueforward flow and a bulk flow reversal occurs.

Flow reversal of surge can result in an increase in temperature withinthe compressor. At the same time, the reversed flow and pressurevariations between the intake and discharge ends of the compressor causerapid changes in axial thrust, thereby risking damage to the thrustbearing and causing blades or vanes to rub on the compressor housing.Furthermore, abrupt speed changes may occur, possibly resulting inoverspeed or underspeed of the compressor rotor.

An antisurge controller is used to protect a compressor from surge bycontinuously monitoring the difference between the compressor'soperating point and its surge limit line. Generally, the antisurgecontroller modulates a recycle or blow-off valve to prevent thecompressor's operating point from reaching the surge limit whilemaintaining other process variables within safe or acceptable limits.

Compressor performance is a function of antisurge performance and otherelements, such as speed, process capacity, and interactions betweenother turbomachines and drivers. Many of these elements are managed witha controller connected to a control valve and actuator.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic of a system in which systems and methods describedherein may, be implemented;

FIG. 2 is a representative compressor map showing a surge limit and asurge control curve;

FIG. 3 is a diagram of exemplary communications between the antisurgecontroller and a field device of FIG. 1;

FIG. 4 is a block diagram of logical components of the antisurgecontroller of FIG. 1;

FIG. 5 is an example of a user interface for a turbocompressor systemaccording to an implementation described herein;

FIG. 6 is a process flow diagram for adapting an antisurge controller tooptimize operating conditions based on field device capabilities,according to an implementation;

FIG. 7 is a representative compressor performance map showing dynamicselection of control algorithms to support different surge controlcurves; and

FIG. 8 is a diagram illustrating exemplary physical components of theantisurge controller of FIG. 1.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings.The same reference numbers in different drawings may identify the sameor similar elements.

Systems and methods described herein relate generally to an automaticcontrol scheme for protecting a turbocompressor from surge. Moreparticularly, implementations described herein relate to methods andsystems for optimizing the surge control curve of a turbocompressorbased on the current conditions and capabilities of the field devicesthat monitor and adjust or control the system.

While the examples provided are based on antisurge control, theinvention applies to other elements of turbomachinery control including,but not limited to, speed control, capacity control, quench control,driver control, sequencing, and control across multiple turbomachines.

To prevent surge, a turbocompressor is typically operated at levels farremoved from the turbocompressor's calculated surge line. However,operating conditions may require the compressor to operate near orbeyond the surge line. An antisurge controller is employed torecirculate flow and move the compressor away from the calculated surgeline; however, this uses energy to recirculate the gas in anon-productive cycle. Minimizing the amount of recirculation isdesirable to reduce energy consumption. Thus, antisurge systems areneeded that allow the turbocompressor to operate more efficiently andthat expand the operating conditions over which the turbocompressor canbe safely used.

Systems and methods described herein utilize data, functionalcapabilities, and information from smart field devices to automaticallyadjust a control algorithm to optimize control performance onturbomachinery. A control system (e.g. an antisurge controller) pollsvarious field devices, such as control valves, actuators, and processtransmitters, for status information. Upon receiving conditions of thefield devices, the control system adjusts its parameters and/oroperating mode(s) to either take advantage of the field device'scapabilities or to fall back to a more conservative control strategy.

FIG. 1 is a schematic of a turbocompressor system 10 in which systemsand methods described herein may be implemented. As shown in FIG. 1,system 10 includes a compressor 100 (also referred to herein asturbocompressor 100) with an antisurge valve 110 connected to anactuator 115. Antisurge controller 180 may set a valve position forantisurge valve 110 by sending a signal to actuator 115. Acurrent-to-pressure transducer (l/P), for example, may convert an analogsignal from antisurge controller 180 into a pressure value for actuator115 to move antisurge valve 110. In the configuration of FIG. 1,antisurge valve 180 is positioned as a recycle valve. In otherimplementation, antisurge valve 180 may be positioned as a blow-offvalve, as might be used for air, nitrogen, and sometimes CO₂compressors. An inlet valve 150 may control gas flow to compressor 100.Similar to antisurge valve 110, a valve position for inlet valve 150 maybe set by antisurge controller 180 by sending a signal to actuator 155.

Process feedback for compressor 100, collected from multiple sensors,may be provided to antisurge controller 180. Sensors may include asuction pressure sensor 120, a discharge pressure sensor 130, and a flowmeter 140. A suction pressure transmitter 125 collects and transmitsdata from suction pressure sensor 120. A discharge pressure transmitter135 collects and transmits data from discharge pressure sensor 130. Aflow transmitter 145 collects and transmits data from flow meter 140. Inone implementation, actuators 115 and 155 may, provide statusinformation, such as a position feedback signal and/or valve diagnosticdata.

Each of antisurge valve 110, actuator 115, suction pressure sensor 120,suction pressure transmitter 125, discharge pressure sensor 130,discharge pressure transmitter 135, flow meter 140, flow transmitter145, inlet valve 150, and actuator 155 may be referred to hereincollectively and generically as “field devices.”

Signals from actuator 115, suction pressure transmitter 125, dischargepressure transmitter 135, flow transmitter 145, and actuator 155 may besent to antisurge controller 1813. Antisurge controller 180 may analyzesignals from actuator 115, suction pressure transmitter 125, dischargepressure transmitter 135, flow transmitter 145, and actuator 155 andcalculate a closed loop response to, for example, a correspondingposition for antisurge valve 110.

As further illustrated, system 10 includes communicative links 160between antisurge controller 180 and each of the field devices. A fielddevice may transmit and receive data via link 160. System 10 may beimplemented to include wireless (e.g., radio frequency) and/or wired(e.g., electrical, optical, etc.) links 160. A communication connectionbetween antisurge controller 180 and the field devices may be direct orindirect. For example, an indirect communication connection may involvean intermediary device not illustrated in FIG. 1. Additionally, thenumber, the type (e.g., wired, wireless, etc.), and the arrangement oflinks 160 illustrated in system 10 are exemplary.

Modern field devices (also referred to as smart devices), such as thoseused in system 10, have functional capabilities, generate additionaldata, and perform diagnostics beyond the basic pressure sensors, flowsensors, and/or temperature sensors provided by older legacy devices.For example, field devices of system 10 may have the capability toself-detect degradation, monitor response times, track calibrationexpiration periods, signal sensor drift, indicate valve movement speeds,predict response times, report precise valve positions, etc.

Under normal operating conditions for compressor 100, antisurgecontroller 180 collects thermodynamic information taken at the inlet andoutlet of the compressor 100. This information typically comprises atleast a pressure differential signal obtained from flow meter 140 andtransmitted by flow transmitter 145; a suction pressure signal, measuredby suction pressure sensor 120 and transmitted by suction pressuretransmitter 125; and a discharge pressure signal, measured by dischargepressure sensor 130 and transmitted by discharge pressure transmitter135. These signals are fed to antisurge controller 180 where the signalsare analyzed and a closed loop response is calculated based on aparticular control algorithm for the turbocompressor system. This closedloop response determines, for example, the set point of an antisurgevalve 110. Signals representing other thermodynamic data, such as one ormore temperatures, may also be used by antisurge controller 180.Mechanical parameters such as compressor rotational speed, inlet guidevane position, or discharge guide vane position may also be measured andtransmitted to the antisurge controller 180.

To prevent surge and corresponding fatigue failures over time,compressor 100 is operated at levels below a calculated surge point fora given operational speed. FIG. 2 illustrates a representativecompressor performance map 200, commonly referred to as a compressormap. The abscissa and ordinate variables are preferably dimensionlessparameters or derived from dimensionless parameters. The abscissavariable, q, is frequently related to the flow rate through compressor100. The ordinate variable, π_(c), is frequently a static pressure ratioor related to a mass specific energy added to the compressed fluid.Other possible coordinate systems may be used.

The individual curves 202 with non-positive slopes (e.g., curves 202-athrough 202-d) in FIG. 2 are performance curves at different compressorrotational speeds. Each performance curve 202 is for a different valueof corrected speed, N_(c), which is a function of the compressorrotational speed, N. The left-most curve is a surge limit curve 210 forcompressor 100 (also referred to as a surge limit line, or simply surgelimit). The area located to the left of and above surge limit curve 210corresponds to a situation in which the operation of compressor 100 isunstable, and is characterized by periodic reversals of flow direction(i.e., surge). The actual surge limit curve may be determinedtheoretically and/or empirically and may be based on the particularimplementation in which compressor 100 operates. In any event, theposition of surge limit curve 210 is used in designing an antisurgecontrol system for compressor 100. The other curve having a positiveslope in FIG. 2 is a surge control curve 220 (or surge control line).Surge control curve 220 is displaced toward the stable operating regionfrom the surge limit (i.e., to the right of and below surge limit curve210) by a safety margin 230.

Surge control curve 220 is defined by an antisurge control systemdesigner or field engineer based on experience or tests. For example,surge control curve 220 may apply a desired safety factor reflected inmargin 230. The size of margin 230 may account for a number of variablesof field devices in system 10, such as response times, signal delays,calibration accuracy, equipment degradation, etc. Generally, inconventional antisurge systems, margin 230 represents a fixed amountbetween surge limit curve 210 and surge control curve 220 along any ofperformance curves 202. That is, margin 230 may provide a known level ofinefficiency in exchange for assured antisurge control. According tosystems and methods described herein, antisurge controller 180 maydynamically adjust the surge control curve (and the corresponding margin230) based on capability feedback from field devices in system 10.

FIG. 3 is a diagram of exemplary communications for dynamicallyoptimizing an antisurge algorithm. Communications in FIG. 3 may occurbetween antisurge controller 180 and field devices 310 within a portion300 of system 10. Each of field devices 310 may correspond to any one ofthe field devices of system 10. Antisurge controller 180 may communicatewith field devices 310 via links 160. Communications shown in FIG. 3provide simplified illustrations of communications in network portion300 and are not intended to reflect every signal or communicationexchanged between devices.

As shown in FIG. 3, antisurge controller 180 may send a polling request312 to field device 310. Generally, polling request 312 may induce fielddevice 310 to provide a capability or status of the field device. Forexample, polling request 312 may request a particular type of data, aconfiguration file, or a status report, etc. In one implementation,polling request 312 may include capability feedback, such as a file orlist of capabilities for field devices 310. In one implementation,polling request 312 may be provided on a periodic basis. Additionally,or alternatively, polling request 312 may be triggered when antisurgecontroller 180 detects an anomaly in process feedback data received (ornot received) from one or more of field devices 310.

Field device 310 may receive polling request 312 and provide a pollingresponse 314 to antisurge controller 180. In one implementation, pollingresponse 314 may indicate a status or a capability of field device 310.Different types of field devices 310 may have different capabilities,such as capabilities to provide different types of data. Field devices310 may provide “capability feedback” to indicate the capabilities ofeach field device (e.g., types of parameters the field device cansupport). Field devices 310 may also provide “process feedback” thatprovides the actual monitoring data for system 10 during operation. Forexample, polling response 314 may include capability feedback, such as afile or list of capabilities of field devices 310. In anotherimplementation, polling response 314 may include monitoring data (e.g.,process feedback) that is indicative of a capability of field device 310to perform a particular function.

Antisurge controller 180 may receive polling response 314 and select 316an appropriate antisurge algorithm (also referred to as a surge controlalgorithm) that is optimized for the collective capabilities of fielddevices 310. For example, if polling responses 314 indicate a full suiteof smart field devices programmable devices) with no degradation withrespect to operating capabilities and self-diagnostic capabilities,antisurge controller 180 may select an antisurge algorithm thatincorporates advanced feedback features to operate with lower margins.As another example, if polling responses 314 indicate that one or moreof field devices 310 have significant degradation, antisurge controller180 may select an antisurge algorithm that excludes the degraded fielddevice 310 and provides comparatively larger margins.

Field devices 310 may also provide raw data 318 and/or diagnostic data320 to antisurge controller 180. Raw data 318 may include, for example,sensor data, position data, or other data directly from sensors.Diagnostic data 320 may include pre-diagnosed data that indicates aparticular condition (e.g., high pressure, valve degradation,calibration certificate expiration, etc.). Depending on thecurrently-selected antisurge algorithm 316, antisurge controller 180 mayapply relevant raw data 318 and diagnostic data 320 to perform antisurgecontrol for system 10. In one implementation, raw data 318 and/ordiagnostic data 320 that are not relevant for the currently-selectedantisurge algorithm 316 may be logged and/or discarded by antisurgecontroller 180.

FIG. 4 is a block diagram illustrating exemplary logical components ofantisurge controller 180 according to an implementation describedherein. The functional components of antisurge controller 180 may beimplemented, for example, via a processor (e.g., processor 820 of FIG.8) executing instructions from memory 230 (memory 830 of FIG. 8) or viahardware. As shown in FIG. 4, antisurge controller 180 may include analgorithm database 410, a polling and monitoring module 420, analgorithm optimizer 430, a system controller 440, a display interface450, a data configuration validator 460, and a calibration module 470.

Algorithm database 410 may store different antisurge algorithms ordifferent components of antisurge algorithms that may apply whendifferent combinations of feedback parameters are available in system10. The different antisurge algorithms may correspond to differentcontrol strategies, which may provide for different margins. Forexample, some antisurge algorithms in algorithm database 410 mayincorporate advanced parameters from field devices 310, such as actuatorresponse times, valve movement times, valve erosion, stiction,temperature, non-responsive or missing process variables, or other fielddevice variables. Application of these advanced parameters may allowantisurge controller 180 to maintain system 10 at operating levelscloser to process limits (e.g., surge limit curve 210) than typicallyused. Conversely, other antisurge algorithms in algorithm database 410may rely on fewer/different parameters and provide a more conservativecontrol strategy (e.g., with larger margins). In still otherimplementations, antisurge algorithms in algorithm database 410 mayaccount for failed sensor components or the ability of field devices 310to provide flags (e.g., diagnostic data 320) to quickly detect andrespond to system conditions.

Polling and monitoring module 420 may provide polling requests (e.g.,polling requests 312) to field devices 310 and process polling responses(e.g., polling responses 314). According to one implementation, pollingand monitoring module 420 may generate different types of pollingrequests for different types field devices 310. For example, a pollingrequest 312 to pressure transmitter 135 may be provided in a differentformat and/or request different information than another polling request312 to actuator 115. In one implementation, polling and monitoringmodule 420 may compile and store a list of parameters currentlyavailable from each field device 310 in system 10. In oneimplementation, polling and monitoring module 420 may convert capabilityfeedback from different field devices 310 in different formats into aunified format for use by algorithm optimizer 430.

According to one implementation, polling and monitoring module 420 mayperform periodic polling of all field devices 310. Additionally, oralternatively, polling and monitoring module 420 may monitor forperiodic capability feedback from field devices 310. Furthermore,polling and monitoring module 420 may issue a polling request if dataanomalies (such as missing data or distorted data) are detected inprocess feedback from field devices 310.

Algorithm optimizer 430 may identify currently available parameters offield devices 310 (e.g., from polling and monitoring module 420) andselect an algorithm from algorithm database 410) for controlling surgein system 10. In one implementation, algorithm optimizer 430 may performa selection process to identify an algorithm that can be supported usingthe currently available parameters while allowing system 10 to operateclosest to process limits (e.g., the smallest safety or surge controlmargin). According to another implementation, algorithm optimizer 430may apply a control algorithm that takes advantage of fast actuatorresponse times and valve movement performance in field devices 310 toavoid rundown surge. For example, when compressor 100 is forced into anemergency stop, rundown surge can be avoided if certain valves areopened (e.g., a blow-off valve) and closed (e.g., a discharge checkvalve) sequentially within a short time period (e.g., fractions of asecond) after an emergency stop. Thus, algorithm optimizer 430 mayautomatically invoke an algorithm to prevent rundown surge whencurrently available parameters of field devices 310 meet required valveresponse times to support such an algorithm.

System controller 440 may implement the algorithm selected by algorithmoptimizer 430. For example, system controller 440 may apply the selectedcontrol algorithm to monitor process feedback from field devices 310 andadjust antisurge valve 110, for example, to maintain selected processmargins 230.

Display interface 450 may display high-resolution and high-speed dataanalysis from one or more field devices 310 in system 10. For example,some field devices 310 may have diagnostic data (e.g., diagnostic data320) that is scanned and monitored within the particular field device310. Display interface 450 may receive the diagnostic data fromindividual field devices 310 and incorporate the diagnostic data into asystem interface, such as user interface 500 described below.

Data configuration validator 460 may compare the data configuration ofantisurge controller 180 with data configurations from field devices 310to confirm, for example, proper configuration of data in antisurgecontroller 180 so that data fields from the field devices 310 andantisurge controller 180 align. Data configuration that can be validatedmay include data field types, field orders, field formats, etc. Forexample, data configuration validator 460 may receive field device datafrom polling and monitoring module 420. Data configuration validator 460may confirm that data formats from field devices 310 match data formatsused, for example, in algorithms of algorithm database 410 and/ordisplay interface 450. Additionally, or alternatively, dataconfiguration validator 460 may use information polled from fielddevices 310 to verify data configuration or automatically setconfiguration parameters of antisurge controller 180.

As one non-limiting illustration of the role of data configurationvalidator 460, assume antisurge controller 180 and a field device 310(e.g., actuator 115) use Modbus serial communications protocol withRS-485 connection standards for communicative link 160. Antisurgecontroller 180 and actuator 115 must agree on what data resides in aparticular field (e.g., field 40002), how many bits are used in thefield (2, 8, 16 bits, etc.), whether big or little endian byte ordersare used, whether the data includes stop bits, etc. if the data linklayer for the communication interface between antisurge controller 180and actuator 115 aligns on both ends of communicative link 160, the twodevices can communicate properly. But if antisurge controller 180 isconfigured with the particular field (e.g., 40002) as the “commandedposition” and actuator 115 uses the “actual position” for the samefield, the data will look correct to antisurge controller 180 but causeantisurge controller 180 to control actuator 115 in an improper fashion.Thus, system 10 may use pre-configured setups for each actuator 115/155,and data configuration validator 460 may verify the readings of eachactuator 115/155 (in the event someone alters the configuration) toensure optimal operation.

According to one implementation, data configuration validator 460 mayautomatically update configuration of data in antisurge controller 180to match configurations provided by field devices 310. In anotherimplementation, data configuration validator 460 may generate an alertsignal upon detecting a discrepancy between data configurations inantisurge controller 180 and data configurations provided by fielddevices 310.

Calibration module 470 may initiate an automatic calibration procedurefor a field device 310, such as actuator 115. For example, calibrationmodule 470 may calibrate actuator 115 based on control responseparameters. In one implementation, calibration module 470 may invoke acalibration algorithm of the actuator 115 to set certain parameters ofthe actuator. Some examples of actuator parameters that need to be setand can be critical to system 10 operation include: gain, deadband, lowtravel cutoff, maximum speed, span distance, normal or reverse acting,and ramp time. Not all types (e.g., different brands/models) of actuator115 have all of these parameters, and there are numerous otherparameters that can be set. The parameters may vary based on the motiveforce (e.g., electric, hydraulic, pneumatic) used by actuator 115 andmanufacturer preferences. Thus, calibration module 470 may storepre-configured parameters and calibration procedures for different typesof field devices 310.

Although FIG. 4 shows exemplary logical components of antisurgecontroller 180, in other implementations, antisurge controller 180 mayinclude fewer logical components, different logical components, oradditional logical components than depicted in FIG. 4. Additionally oralternatively, one or more logical components of antisurge controller180 may perform functions described as being performed by one or moreother logical components.

FIG. 5 is an example user interface 500 that may be generated by displayinterface 450. As shown in FIG. 5, user interface 500 may include asystem graph 510, a system control pallet 520, and field deviceparameter readings 530.

System graph 510 may include a surge limit curve, a surge control curve,and performance curves for particular system 10. In one implementation,system graph 510 may include a visual log 512 of historical performanceof the system.

System control pallet 520 may include operation status indications andcontrol settings for system 10. In one implementation, system controlpallet 520 may include multiple menus and user-defined configurations.

Field device parameter readings 530 may include a list of parametersavailable to be used with each field device 310 in system 10. Parametersin field device parameter readings 530 may correspond to capabilities ofdifferent field devices 310. For example, parameters listed in fielddevice parameter readings 530 may include parameters corresponding tofield device 310 capabilities detected by polling and monitoring module420. In one implementation, parameters displayed in field deviceparameter readings 530 may be shown in different colors or sizesdepending on whether or not the parameters are currently being used fora current antisurge algorithm (e.g., as selected by algorithm optimizer430).

Although user interface 500 depicts a variety of information, in otherimplementations, user interface 500 may depict less information,additional information, different information, or differently arrangedinformation than depicted in FIG. 5.

FIG. 6 is a flow diagram of a process 600 for dynamically adapting anantisurge controller to optimize operating conditions based on fielddevice capabilities. According to one implementation, process 600 may beperformed by antisurge controller 180. In another implementation,process 600 may be performed by antisurge controller 180 in conjunctionwith field devices 310.

As shown in FIG. 6, process 600 may include identifying field devicecapabilities for a turbocompressor system (block 610). For example,according to one implementation, antisurge controller 180 may poll fielddevices 310 for capabilities. In another implementation, capabilities offield devices 310 may be determined by antisurge controller 180 based onperiodic reports or based on the types of process feedback data providedto antisurge controller 180 by field devices 310. Basic capabilities mayinclude, for example, detection of pressure, temperature, flow, andcurrent. More advanced capabilities may include, for example, valvediagnostics, response times (for valves and/or sensors), valve movementtimes, valve position indications, etc.

Process 600 may also include selecting an optimal control algorithmbased on the identified capabilities (block 620) and receiving fielddevice feedback data (block 630). For example, antisurge controller 180may select an algorithm (e.g., from algorithm database 410) forcontrolling surge in system 10. In one implementation, antisurgecontroller 180 may select an algorithm that provides the smallest surgecontrol margin using the currently-available parameters. Additionally,or alternatively, antisurge controller 180 may select an algorithm toprevent rundown surge, as described above. Antisurge controller 180 mayreceive feedback data for system 10 from field devices 310. Feedbackdata may include sensor data (e.g., raw data 318 from suction pressuretransmitter 125, discharge pressure transmitter 135, flow transmitter145, etc. valve position data (e.g., raw data 318 from antisurge valve110, inlet valve 150, etc.), and/or diagnostic flags (e.g., diagnosticdata 320).

Process 600 may further include compiling and/or displaying the feedbackdata with system information (block 635), and determining if thefeedback data has a monitoring impact (block 640). For example,antisurge controller 180 may receive raw data 318 and/or diagnostic data320 from field devices 310. Antisurge controller 180 may present some orall of raw data 318 and diagnostic data 320 in conjunction with overallsystem data. In one implementation, display interface 450 of antisurgecontroller 180 may present raw data 318 and diagnostic data 320 fromfield devices 310 within real-time user interface 500. Antisurgecontroller 180 may also inspect and process raw data 318 and diagnosticdata 320 to determine if any of raw data 318 and/or diagnostic data 320indicates an impact on the performance or the implementation of thecurrently selected control algorithm (e.g., selected in block 620). Forexample, in one implementation, antisurge controller 180 (e.g., pollingand monitoring module 420) may inspect raw data 318 from field devices310 for missing or distorted data. Additionally, or alternatively,antisurge controller 180 may detect diagnostic data 320 that indicates aparticular condition of a field device 310 which would impact theeffectiveness of the currently selected control algorithm.

If the feedback data does not indicate any monitoring impact (block640—No), process 600 may include determining if new polling is neededfor the field devices (block 650). For example, antisurge controller 180may perform periodic polling of field devices 310 to ensure currentcapabilities of field devices 310 can support the currently selectedcontrol algorithm. Thus, antisurge controller 180 may determine if apolling window has expired, triggering a need for a new polling inquiry(e.g., from polling and monitoring module 420).

If new polling is needed for the field devices (block 650—Yes), process600 may return to block 610 to identify field device capabilities. Ifnew polling is not needed for the field devices (block 650—No), process600 may return to block 630 and continue to receive field devicefeedback data.

If the feedback data indicates there is monitoring impact (block640—Yes), process 600 may include reporting a feedback change (block660), and returning to block 610 to identify field device capabilities.For example, if any of raw data 318 and/or diagnostic data 320 indicatesan impact on the performance or the implementation of the currentlyselected control algorithm (e.g., selected in block 620), antisurgecontroller 180 may report the instance (e.g., via user interface 500, aseparate electronic notification, an audible signal, etc.). Antisurgecontroller 180 may also poll field devices 310 for conditions andcapabilities of field devices 310.

Based on either the interpretation of raw data 318 and/or diagnosticdata 320, or the polling result, antisurge controller 180 mayautomatically and dynamically adjust parameters (e.g., threshold valuesfor the current control algorithm) and/or operating mode (e.g., changingthe control algorithm) to either take advantage of the field devices'capabilities or fall back to a more conservative control strategy. Inanother implementation, antisurge controller 180 may provide (e.g., viaa user interface 500), an alert signal to an operator/engineerindicating the selection of the updated control algorithm. In anotherimplementation, antisurge controller 180 may invoke specializedoperating modes of the field device (e.g., dead time on seat, “QuickTrack”™, etc.) to take advantage of built-in functions of the fielddevice.

While some portions of the flow diagram in FIG. 6 are represented as asequential series of blocks, in other implementations, different blocksmay be performed in parallel or in series. For example, in oneimplementation, capability feedback and process feedback may be receivedfrom field devices 310 simultaneously or asynchronously.

FIG. 7 illustrates a representative compressor performance map 700showing dynamic selection of control algorithms to support differentsurge control curves 220. According to an implementation, antisurgecontroller 180 may dynamically change antisurge algorithms to enforcedifferent surge control curves 220 (e.g., surge control curve 220-a,220-b, 220-c). The different surge control curves 220 provide differentmargins 230 (e.g., margins 230-a, 230-b, 230-c).

As shown in FIG. 7, surge limit curve 210 represents the limits ofstable operation for compressor 100. After polling field devices 310 forconditions and capabilities of field devices 310, antisurge controller180 may identify advanced features of one or more field devices 310 thatpermit use of a control algorithm to implement surge control curve 220-awith a relatively small margin 230-a.

Assume that antisurge controller 180 receives capability feedback fromone of field devices 310 indicting a condition that may cause delayedresponse or inaccurate data. For example, a valve (e.g., antisurge valve110) may detect and report (e.g. via diagnostic data 320) stiction of avalve stem. Until a physical correction of antisurge valve 110 can beperformed, the stiction may require a control signal to overshoot adesired set point in order to initiate any valve movement. In responseto the stiction indication (and regardless of the actual operatingconditions of system 10), antisurge controller 180 may dynamicallychange the control algorithm parameters to implement surge control curve220-b with a relatively larger margin 230-b.

In another example, a pressure sensor discharge pressure transmitter135) may detect and report pressure sensor drift. In still anotherexample, a valve (e.g., antisurge valve 110) may detect and reporterosion of a valve seat. In further example, one of field devices 310may detect that a calibration certification has expired (implyingreadings from the particular field device 310 may no longer bereliable). According to implementations described herein, upon detectingfailure or degradation in a field device 310, antisurge controller 180may fall back to more conservative para e s (e.g., to implement a surgecontrol curve 220 with a relatively, larger margins 230) or switch to amore conservative control algorithm that does not rely on capabilitiesof field devices 310 that may provide delayed or inaccurate data.

Still referring to FIG. 7, assume a field device 310 is serviced orupgraded. For example, a valve actuator (e.g., valve actuator 115) maybe upgraded to provide faster response times than previously used insystem 10. As another example, a valve (e.g., antisurge valve 110) maybe upgraded to provide faster movement/adjustment speeds. As stillanother example, a field device 310 may be re-calibrated. Antisurgecontroller 180 may poll the field devices 310 and identify the upgradedfeatures. Antisurge controller 180 may identify the new or verifiedcapabilities of field devices 310 and select an algorithm that providesthe smallest surge control margin supported by the available fielddevice capabilities. As shown in FIG. 7, antisurge controller 180 maychange to a control algorithm to implement surge control curve 220-cwith a smallest margin 230-c.

FIG. 8 is a diagram illustrating exemplary physical components ofantisurge controller 180. Antisurge controller 180 may include a bus810, a processor 820, a memory 810, an input component 840, an outputcomponent 850, and a communication interface 860.

Bus 810 may include a path that permits communication among thecomponents of antisurge controller 180. Processor 820 may include aprocessor, a microprocessor, or processing logic that may interpret andexecute instructions. Memory 830 may include any type of dynamic storagedevice that may store information and instructions (e.g., software 835),for execution by processor 820, and/or any type of non-volatile storagedevice that may store information for use by processor 820.

Software 835 includes an application or a program that provides afunction and/or a process. Software 835 is also intended to includefirmware, middleware, microcode, hardware description language (HDL),and/or other form of instruction.

Input component 840 may include a mechanism that permits a user to inputinformation to antisurge controller 180, such as a keyboard, a keypad, abutton, a switch, a touch screen, etc. Output component 850 may includea mechanism that outputs information to the user, such as a display, aspeaker, one or more light emitting diodes (LEDs), etc.

Communication interface 860 may include a transceiver that enablesantisurge controller 180 to communicate with other devices and/orsystems via wireless communications (e.g., radio frequencycommunications), wired communications, or a combination of wireless andwired communications. For example, communication interface 860 mayinclude mechanisms for communicating with another device or system, suchas suction pressure transmitter 125, discharge pressure transmitter 135,and flow transmitter 145, via a network, or to other devices/systems,such as a system control computer that monitors operation of multiplesystems 10 (e.g., in a steam plant or another type of plant). In oneimplementation, communication interface 860 may be a logical componentthat includes input and output ports, input and output systems, and/orother input and output components that facilitate the transmission ofdata to/from other devices.

Antisurge controller 180 may perform certain operations in response toprocessor 820 executing software instructions (e.g., software 835)contained in a computer-readable medium, such as memory 830. Acomputer-readable medium may be defined as a non-transitory memorydevice. A non-transitory memory device may include memory space within asingle physical memory device or spread across multiple physical memorydevices. The software instructions may be read into memory 830 fromanother computer-readable medium or from another device. The softwareinstructions contained in memory 830 may cause processor 820 to performprocesses described herein. Alternatively, hardwired circuitry may beused in place of or in combination with software instructions toimplement processes described herein. Thus, implementations describedherein are not limited to any specific combination of hardware circuitryand software.

Antisurge controller 180 may include fewer components, additionalcomponents, different components, and/or differently arranged componentsthan those illustrated in FIG. 8. As an example, in someimplementations, a display may not be included in antisurge controller180. In these situations, antisurge controller 180 may be a “headless”device that does not include input component 840 and/or output component850. As another example, antisurge controller 180 may include one ormore switch fabrics instead of, or in addition to, bus 810.Additionally, or alternatively, one or more components of antisurgecontroller 180 may perform one or more tasks described as beingperformed by one or more other components of antisurge controller 180.

According to systems and methods described herein, an antisurgecontroller for a turbocompressor system may store, in a local memory ofthe antisurge controller, multiple control algorithms. The antisurgecontroller may identify capabilities of field devices in theturbocompressor system. The field devices include an antisurge valve andmultiple sensors. The antisurge controller may select one of themultiple control algorithms based on the identified capabilities andapply the selected control algorithm to the turbocompressor system. Insome instances, the selected control algorithm may provide the smallestsurge control margin, of the surge control margins in the multiplecontrol algorithms, that are supported by the identified capabilities.

The foregoing description of exemplary implementations providesillustration and description, but is not intended to be exhaustive or tolimit the embodiments described herein to the precise form disclosed.Modifications and variations are possible in light of the aboveteachings or may be acquired from practice of the embodiments.

Although the invention has been described in detail above, it isexpressly understood that it will be apparent to persons skilled in therelevant art that the invention may be modified without departing fromthe spirit of the invention. Various changes of form, design, orarrangement (e.g., use in capacity control, speed control, or othercontrol applications) ray be made to the invention without departingfrom the spirit and scope of the invention.

No element, act, or instruction used in the description of the presentapplication should be construed as critical or essential to theinvention unless explicitly described as such. Also, as used herein, thearticle “a” is intended to include one or more items. Further, thephrase “based on” is intended to mean “based, at least in part, on”unless explicitly stated otherwise.

Embodiments described herein may be implemented in many different formsof software executed by hardware. For example, a process or a functionmay be implemented as “logic,” a “component,” or an “element.” Thelogic, the component, or the element, may include, for example, hardware(e.g., processor 820, etc.), or a combination of hardware and software(e.g., software 835). Embodiments have been described without referenceto the specific software code because the software code can be designedto implement the embodiments based on the description herein andcommercially available software design environments and/or languages.For example, various types of programming languages including, forexample, a compiled language, an interpreted language, a declarativelanguage, or a procedural language may be implemented.

All structural and functional equivalents to the elements of the variousaspects set forth in this disclosure that are known or later come to beknown to those of ordinary skill in the art are expressly incorporatedherein by reference and are intended to be encompassed by the claims. Noclaim element of a claim is to be interpreted under 35 U.S.C. § 112(f)unless the claim element expressly includes the phrase “means for” or“step for.”

Use of ordinal terms such as “first,” “second,” “third,” etc., in theclaims to modify a claim element does not by itself connote anypriority, precedence, or order of one claim element over another, thetemporal order in which acts of a method are performed, the temporalorder in which instructions executed by a device are performed, etc.,but are used merely as labels to distinguish one claim element having acertain name from another element having a same name (but for use of theordinal term) to distinguish the claim elements.

What is claimed is:
 1. A method of antisurge control for aturbocompressor system including an antisurge controller, the methodcomprising: storing, in a memory of the antisurge controller, multiplecontrol algorithms; identifying, by the antisurge controller,capabilities of field devices in the turbocompressor system, wherein thefield devices include an antisurge valve and multiple sensors, andwherein the identifying includes sending a polling request, to one ormore of the field devices and receiving, from the one or more of thefield devices, a polling response that includes the capabilities of theone or more field devices; selecting, by the antisurge controller, oneof the multiple control algorithms and one or more operating features ofthe field devices based on the identified capabilities; and applying, bythe antisurge controller, the selected control algorithm to theturbocompressor system.
 2. The method of claim 1, further comprising:receiving process feedback from the field devices; determining; by theantisurge controller, that the process feedback has a monitoring impact;identifying, by the antisurge controller and in response to thedetermining, updated capabilities of field devices in theturbocompressor system; and selecting, by the antisurge controller,another one of the multiple control algorithms based on the updatedcapabilities.
 3. The method of claim 2, wherein receiving the processfeedback from the field devices includes: receiving raw data from thefield devices.
 4. The method of claim 2, wherein receiving the processfeedback from the field devices includes: receiving a signal indicatinga pre-diagnosed condition of one of the field devices.
 5. The method ofclaim 2, further comprising: providing, via a user interface associatedwith the antisurge controller, an alert signal indicating the selectionof the other one of the multiple control algorithms.
 6. The method ofclaim 1, further comprising receiving process feedback from the fielddevices; and determining, by the antisurge controller, that the processfeedback does not have a monitoring impact.
 7. The method of claim 1,further comprising: receiving process feedback from the field devices;and displaying, by the antisurge controller, the process feedback fromthe field devices for the turbocompressor system.
 8. The method of claim1, wherein identifying capabilities of the field devices comprises:identifying self-diagnostic capabilities of the one or more fielddevices.
 9. The method of claim 1, further comprising: displaying, bythe antisurge controller and via a user interface, the capabilities ofthe one or more field devices.
 10. The method of claim 1, wherein theone or more field devices includes an antisurge valve, a pressuretransmitter, and a flow transmitter, and wherein the polling responsefrom each of the one or more field devices is received with a differentformat.
 11. The method of claim 1, further comprising: comparing, by theantisurge controller, a data configuration from the polling responsewith a corresponding data configuration of the antisurge controller; andgenerating, by the antisurge controller, an alert signal when adiscrepancy is detected, based on the comparing, between the dataconfiguration from the polling response and the corresponding dataconfiguration.
 12. The method of claim 1, further comprising: invoking,by the antisurge controller and based on the polling response, acalibration algorithm of a control valve actuator to set parameters ofthe control valve actuator.
 13. The method of claim 1, wherein thecapabilities include one or more of: stiction detection, or valveerosion detection.
 14. The method of claim 1, wherein selecting one ofthe multiple control algorithms includes: selecting the one of themultiple control algorithms that has a smallest surge control margin, ofthe surge control margins in the multiple control algorithms that aresupported by the identified capabilities.
 15. An antisurge controllerfor a turbocompressor system, comprising: a memory device for storinginstructions; a communication interface for receiving data from fielddevices in the turbocompressor system; and a processor configured toexecute the instructions to: store, in the memory, multiple controlalgorithms, obtain, via the communication interface, a list ofcapabilities of field devices in the turbocompressor system, wherein thefield devices include an antisurge valve and multiple sensors, display,via a user interface, parameters for the capabilities of the fielddevices, select one of the multiple control algorithms based on theidentified capabilities, and apply the selected control algorithm to theturbocompressor system.
 16. The antisurge controller of claim 15,wherein the processor is further configured to execute the instructionsto: identify, after the applying, updated capabilities of the fielddevices in the turbocompressor system; and select another one of themultiple control algorithms based on the updated capabilities.
 17. Theantisurge controller of claim 16, wherein, when identifying the updatedcapabilities, the processor is further configured to execute theinstructions to: receive process feedback from the field devices; anddetermine that the process feedback has a monitoring impact.
 18. Theantisurge controller of claim 17, wherein, when receiving the processfeedback from the field devices, the processor is further configured toexecute the instructions to: receive a signal indicating a pre-diagnosedcondition of one of the field devices.
 19. The antisurge controller ofclaim 15, wherein, when obtaining a list of capabilities of fielddevices, the processor is further configured to execute the instructionsto: send a polling request to one or more of the field devices; andreceive, from the one or more of the field devices, a polling responsethat includes the capabilities of the one or more field devices.
 20. Theantisurge controller of claim 15, wherein, when obtaining a list ofcapabilities of field devices, the processor is further configured toexecute the instructions to: receive polling responses with differentformats from the one or more field devices.
 21. The antisurge controllerof claim 15, wherein, when obtaining a list of capabilities of fielddevices, the processor is further configured to execute the instructionsto: identify one or more valve response times for the field devices, andwherein, when selecting one of the multiple control algorithms based onthe identified capabilities, the processor is further configured toexecute the instructions to: invoke an algorithm to prevent rundownsurge when the one or more valve response times meet required valveresponse times to the algorithm to prevent rundown surge.
 22. Anon-transitory computer-readable medium containing instructionsexecutable by at least one processor, the computer-readable mediumcomprising one or more instructions to: store; in a memory, multiplesurge control algorithms for a turbocompressor system; obtain, via acommunication interface, a list of capabilities of field devices in theturbocompressor system, wherein the field devices include an antisurgevalve and multiple sensors, and wherein the obtaining includes sending apolling request to one or more of the field devices and receiving, fromthe one or more of the field devices, a polling response that includesthe capabilities of the one or more field devices; select one of themultiple surge control algorithms based on the identified capabilities;and apply the selected surge control algorithm to the turbocompressorsystem.
 23. The non-transitory computer-readable medium claim 22,further comprising one or more instructions to: identify, after theapplying, updated capabilities of the field devices in theturbocompressor system; and select another one of the multiple surgecontrol algorithms based on identifying the updated capabilities.
 24. Anantisurge controller for a turbocompressor system, comprising: a memorydevice for storing instructions; a communication interface for receivingdata from field devices in the turbocompressor system; and a processorconfigured to execute the instructions to: send a polling request to oneor more field devices in the turbocompressor system, wherein the fielddevices include an antisurge valve and multiple sensors, receive, fromthe one or more of the field devices, a polling response that includesthe capabilities of the one or more field devices, compare a dataconfiguration from the polling response with a corresponding dataconfiguration of the antisurge controller, and generate an alert signalwhen a discrepancy is detected between the data configuration from thepolling response and the corresponding data configuration, based on thecomparing.
 25. The antisurge controller of claim 24, wherein theprocessor is further configured to execute the instructions to:automatically update the corresponding data configuration to match thedata configuration from the polling response.